\myChapter{System Implementation}\label{ch:implementation}

This chapter presents the implementative details, of the project. The architecture defined in the Chapter~\ref{ch:design}, have been implemented following the methodology described in the Chapter~\ref{ch:methodology}. The main section of the implementation is represented by the Visual Workflow Representation, that has been breakdown in two packages:
\begin{itemize}
	\item OGSA-DAI workflow model
	\item Workflow Visual Editor
\end{itemize}
Both the packages are divided in smaller sub-modules, according to EMF and GMF specification.

Another difference between the architecture specification and the implementation, is that modules with different functionality but similar implementation, have been packaged together. The two modules that are acting has OGSA-DAI clients (the Resource and Activity Discovery and the Workflow Execution), are considered has belonging to a single package named \textit{OGSA-DAI client}.

The following sections describes some implementation details of each package, providing code snippets when necessary.

\section{OGSA-DAI client}
The implementation of this package consists in one single java class, that using CTW functionalities acts as client for OGSA-DAI and expose four methods to the other packages. In the Figure~\ref{fig:class_diagram_serverClient} is shown the class diagram, with the methods exposed.
\begin{figure}[htb]
    \centering
    \includegraphics[width=0.9\textwidth]{gfx/class_diagram_serverClient}
    \caption{Model diagram 1}\label{fig:class_diagram_serverClient}
\end{figure}

\lstset{language=Java, caption=WorkflowType and ActivityType schema definition, label=lst:listResource}
\begin{lstlisting}
public RequestResource executeRequest(String docPath)
 	throws Exception {
 
 	String drerIDStr = "DataRequestExecutionResource";
 	ResourceID drerID = new ResourceID(drerIDStr);
 	RequestExecutionType execType = RequestExecutionType.SYNCHRONOUS;
 	
 	DataRequestExecutionResource drer = server
 		.getDataRequestExecutionResource(drerID);
 	DocumentWorkflow workflow = new DocumentWorkflow(docPath);
 	RequestResource request = null;
 	try {
 		request = drer.execute(workflow, execType);
 	} catch (RequestExecutionException e) {
 		System.out.println(e.getRequestResource().getRequestStatus());
 		throw e;
 	}
 	return request;
}
\end{lstlisting}
The Listing~\ref{lst:listResource} shows the implementation of the workflow execution methods. How is possible to notice from the code, the method reads an xml file containing the workflow from the file system. This solution is inefficient, mainly because the xml document is already loaded with the workflow diagram. It woulb be easy to add a new method that accepts XML Document object as parameter, but due to problems that are described in the section\ref{sec:serializaion} it has not be possible to do it.

\section{Modeling the OGSA-DAI workflow}
The MDA methodology requires to build a Platform Independent Model: this task is accomplished using the capability given by EMF to generate models starting from an XML Schema definition. The OGSA-DAI extension pack provides an XML Schema definition (XSD) file in which a workflow is defined in terms of XML Schema elements. 

\lstset{language=XML, caption=WorkflowType and ActivityType schema definition, label=lst:wf_schema}
\begin{lstlisting}
  <!-- SNIP -->  
  <!-- Elements describing a workflow -->
  <xsd:complexType name="WorkflowType">
    <xsd:choice>
      <xsd:element name="parallel" type="tns:ParallelType" />
      <xsd:element name="sequence" type="tns:SequenceType" />
      <xsd:element name="pipeline" type="tns:PipelineType" />
    </xsd:choice>
  </xsd:complexType>
 <!-- SNIP -->  
  <!-- Activity type -->
  <xsd:complexType name="ActivityType">
    <xsd:sequence>
      <xsd:element name="inputs" type="tns:InputsType"/>
      <xsd:element name="outputs" type="tns:OutputsType"/>
    </xsd:sequence>
    <xsd:attribute name="name" type="xsd:string" use="required"/>
    <xsd:attribute name="instanceName" type="xsd:ID" use="required"/>
    <xsd:attribute name="resource" type="xsd:string" use="optional"/>
  </xsd:complexType>
  <!-- SNIP -->
\end{lstlisting}

The XSD shown in Listing~\ref{lst:wf_schema} is imported as EMF model, generating an \textit{.ecore} file and a \textit{.genmodel} file. The ecore file describes the model it self, meanwhile the genmodel serves as decorator indicating some model properties such as the Java package names, the serialization form, etc. 

The functional unit of model is the \textit{ActivityType} element, Figure~\ref{fig:model_diagram_top} shows how it is modelled. An ActivityType has three attributes (corrisponding to the EMF class \textit{EAttribute}): 
\begin{itemize}
	\item \textit{instanceName}: name of the activity which is an arbitrary name assigned by the user but it has to be unique within the scope of the request
	\item \textit{resource}:target resource of the activity. It is obtained from the OGSA-DAI service and refers to the resource that are deployed on the service. An activity can also not being associated with a resource , i.e. a transformation activity, and for this reason attribute is optional
	\item \textit{name}: of the activity on the OGSA-DAI server. It is obtained from the OGSA-DAI service and depends on the target resource selected for the activity. If no resource is selected, the service will return a default activities list.
\end{itemize}
An ActivityType \textit{contains} one \textit{InputsType} and one \textit{OuputsType}, that are two class used to reference other input and ouput objects. The \textit{contain} feature is modelled using an EMF \textit{EReference}. An input in a OGSA-DAI workflows can be represented by a data type, modeled by the class \textit{DataType}, or by an InputStream. InputStream means that the data that will be given as input to the activity comes form a different activity, that uses a OutputStream to send as output the data.

\begin{figure}[htb]
    \centering
    \includegraphics[width=0.95\textwidth]{gfx/model_diagram_top.pdf}
    \caption{Model diagram 1}\label{fig:model_diagram_top}
\end{figure}

The Figure~\ref{fig:model_diagram_bottom} shows the structure of a request. A request has a tree structure with pipelines as leaves. The nodes of the tree are called workflows. A workflow can either be a parallel (modelled as \textit{ParallelType}), a sequence (modelled as \textit{SequenceType}) or a pipeline workflow(modelled as \textit{PipelineType}). Parallel and sequence workflows may contain any number of child workflows. A sequence indicates that its child workflows are executed in sequence. A parallel indicates that its child workflows are executed in parallel. There is exactly one top level workflow. A pipeline contain only activities but no other workflows. 
\begin{figure}[htb]
    \centering
    \includegraphics[width=0.95\textwidth]{gfx/model_diagram_bottom.pdf}
    \caption{Model diagram 2}\label{fig:model_diagram_bottom}
\end{figure}

\subsection{Generated Code}
Once the model has been designed using the EMF genmodel file it's possible to generate the Plaform Specific Model, and then model code\footnote{See Appendinx~\ref{ch:appendix_code} for more details about modules}.  The generated code contains:
\begin{enumerate}
	\item Model: provides Java interfaces and implementation classes for all the classes in the model, plus a factory and package (meta data) implementation class. For each metamodel element there is an interface and an implementation class generated.
	\item Adapters: generates implementation classes (called ItemProviders) that adapt the model classes for editing and display.
	\item The .edit project contains a number of utilities for building editors like standard table and property sheet views.
\end{enumerate}

\subsection{Code customization}
The EMF aim is to generate automatically as much code as possible, but sometimes for really domain specific problem, it has been required to customize the generated code. According with the MVC patter the EMF.Edit code, that in the project can be considered as a controller, has no knowledge about the business layer, that in the project is represented by the OGSA-DAI client. In order to implement one of the functional requirements, the controller has to use the OGSA client to query what activities and resource are available, and dispatch them to the View. This behaviour cannot be modelled (moreover it will be against the MDA principles) and thus a customization of the generated code has been required. The Figure~\ref{fig:sequence_diagram_listres} shows how  \textit{ActivityTypeItemProvider} class has been modified to call methods from the ServerClient.
\begin{figure}[htb]
    \centering
    \includegraphics[width=1.1\textwidth]{gfx/sequence_diagram_listres}
    \caption{Sequence diagram}\label{fig:sequence_diagram_listres}
\end{figure}
 

\section{Building the Workflow Visual Editor}\label{sec:gmf}
To build the Workflow Visual Editor on top of the EMF ecore model, there are a number of additional models that have to be defined. They have already been described in the introduction section in previous chapter: the next sections describe the steps to generate the GMF diagram editor. The models (corresponding to many steps) to be defined are:
\begin{enumerate}
	\item \textit{.gmfgraph}: A model defining the graphical notation including shapes decorations and graphical nodes and connections.
	\item \textit{.gmftool}: A model for the editor's palette and other tooling.
	\item \textit{.gmfmap}: A mapping model that binds gmfgraph and gmftool to the ecore file. The two models defined above are technically (but not conceptually) independent of our domain metamodel.
\end{enumerate}

\subsection{GMF Graph definition}
The graphical elements that are used to compose a workflow are essentially: 
\begin{itemize}
	\item Activity element: is the visual representation of the ActivityType element of the model
	\item Workflow elements: the workflows elements to be defined are four representing WorkflowType, PipelineType SequenceType and ParallelType
	\item Input and Output elements: this group of elements represent InputsType, OutputsType, InputType, OutputType, InputStreamType, InputLiteralType.
	\item Link element: is the visual representation of the link between an InputStream and an OutputStream
\end{itemize}
\begin{figure}[htb]
    \centering
    \includegraphics[width=0.95\textwidth]{gfx/screenshot_gmfgraph}
    \caption{GMF Graph definition}\label{fig:screenshot_gmfgraph}
\end{figure}
The Figure~\ref{fig:screenshot_gmfgraph} shows some sections of the gmfgraph model:  on top is shown the set of figures that are used to represent, graphically, the domain model elements.  Any sort of figure can be constructed with the available options by adding them as a New Child to the present Figure. Looking at the details about the Activity Figure, it's represented with a \textit{rounded rectangle} and is decorated with three attributes: RGB colour to set the foreground, a layout definition and a label.
After that all the figure are defined, they have to be linked with a GMF node: this is useful to refer to the node avoiding reference to the figure that represent it, adding a level of indirection.
Two other important elements that are shown in the figure are the \textit{Connection} element, that represents a graphically connection between two nodes, and the \textit{Compartment} element. A compartment is a graphical element that has no counterpart in the ecore model, and is useful to contain other elements, providing feature such the possibility to be collapsed and scroll bars to be navigated.

\subsection{The Tool Model}
The .gmftool model defines the set of palette entries. A palette is a set of buttons on the right of an editor that allows to add model elements to the domain model instance. The Figure~\ref{fig:screenshot_gmftool} shows the elements that are defined in the model, and Figure~\ref{fig:screenshot_palette} shows how the palette is displayed the visual editor.

\begin{figure}[htb]
    \centering
    \subfloat[Tool]{\label{fig:screenshot_gmftool}\includegraphics[width=0.8\textwidth]{gfx/screenshot_gmftool}}
    \subfloat[Palette]{\label{fig:screenshot_palette}\includegraphics[width=0.2\textwidth]{gfx/screenshot_palette}}
    \caption{Toos and Palette}
\end{figure}

\subsection{The Mapping Model}
This is the most complex model: here the domain, the graphical definition, and the tooling definition, are bounded together in a model that will be used to generate the \textit{.gmfgen} model. The Figure~\ref{fig:screenshot_gmfmap} shows some sections of the mapping model.
\begin{figure}[htb]
    \centering
    \includegraphics[width=1.1\linewidth]{gfx/screenshot_gmfmap}
    \caption{GMF Graph definition}\label{fig:screenshot_gmfmap}
\end{figure}
In the figure is possible to recognize several important element of the model: first of all this model establishes the hierarchy that will be used in diagram. The first level of the hierarchy is represented by elements classified as \textit{Top Node Reference} and in the specific mapping model they graphically  represents the three different type of workflows. 

Another detail that is shown in the figure is how the leafs of the workflow, defined in the gmfgraph model as plain and with no relationship with other elements, are nested in a hierarchy that reflects the way the workflow will be composed.

On the bottom part of the Figure, are shown the propertied of a mapped element. A node mapping an Activity is characterized by a \textit{Domain meta Information} equal to ActivityType, by a \textit{Diagram Node}(the actual element displayed on the diagram) equal to Node Activity and a Tool.
\subsection{Generated Code}
Using the mapping model, is possible to generate the GMF generator model, that is the last step in the process of defining a GMF editor. This last model refers to the process of generating a model, giving the possibility to tune the code generation process. It will not add new elements to the diagram, but just decorate it. 

The amount Java classes generated running the model, is very big and describing them will be beyond the scope of the thesis (and probably impossible). 

\section{Diagram Serialization and Validation}\label{sec:serialization}
\subsection{Diagram Serialization}
The diagram serialization implementation comes ``for free'' with the decision of using EMF to design the model. The possibility  to persist models, give the possibility to integrate it with other applications, and it's one of the most powerful EMF features.

EMF core models are persisted using XMI, and the framework includes a default XMI serializer that can be used to persist user defined models. For the purpose of the project, XMI serialization is not a good solution, considering that the OGSA-DAI document client, accepts workflow define in a XML format. Above the default serialization support, EMF allows to serialize model in any persistant format. In this case in necessary to write a serializer for the model, but again, EMF provides a serializator  to persist objects as an XML instance document conforming to a XSD schema.

Once the EMF model has been generated, the class that is in charge of serializing and de-serializing the model is 
\textit{ModelResourceFactory}, and is automatically used by the GMF framework to handle the ``Save'' and ``Open'' action. In this context, the developer would never been involved in serialization issues. 

To fulfil one of the requirements it has been necessary to add custom code, in order to obtain a representation of the workflow and execute it. The first approach that has been investigated is to use an in memory representation, avoiding to serialize the the model on the file-system.

The code in Listing\ref{lst:serial1} shows how the ModelResourceImpl class is used to serialize the diagram, on a XML document. 
\lstset{language=Java, caption=WorkflowType and ActivityType schema definition, label=lst:serial1}
\begin{lstlisting}
documentBuilder = documentBuilderFactory.newDocumentBuilder();
			
Document document = documentBuilder.newDocument();

for(Resource resource: resourceSet.getResources()){		
	if(resource instanceof ModelResourceImpl){
		((XMLResource)resource).save (document, null, null);
		break:
	}
}
DocumentClient   clientDoc = new ServerClient(serverURL);
DocumentWorkflow workflowDoc =  clientDoc.executeRequest(document);
\end{lstlisting}
This solution, even if is really efficient, presents a conflict between the different \textit{xerces} libraries that are used by OGSA-DAI and by EMF.  A workaround to this problem is presented by the code in Listing~\ref{lst:serial2}, that uses the ModelResourceImpl to serialize the model on a temporary file created using the URI associated to the model.

\lstset{language=Java, caption=WorkflowType and ActivityType schema definition, label=lst:serial2}
\begin{lstlisting}
for (Object obj : styleList) {
	if (obj instanceof PropertiesStyle)				
		style = (PropertiesStyle) obj;			
	}
	if(style != null){
		fileName = "/tmp/"+EcoreUtil.getURI((EObject)style).fragment()+".xml";			
		serverURL = style.getServerURL();			
	}
}
FileOutputStream fos = new FileOutputStream(new File(fileName));
for(Resource resource: resourceSet.getResources()){		
 	if(resource instanceof ModelResourceImpl})		
	resource.save(fos,null);
}
			
ServerClient server= new ServerClient(serverURL);			
RequestResource request =  server.executeRequest(fileName);
\end{lstlisting}
\subsection{Diagram Validation}
One of the non-user requirements identified in the first section of the project, is that the diagram that is produced by the editor has to be \textit{valid}.  Adopting EMF as modeling language made been possible to implement the validation using the \textit{EMF TValidation Framework}. The EMFT Validation framework provides a means to ensure the well-formedness of EMF models. The EMF generated code, uses the Validation framework, to build a basic validator, that checks the in memory model against the ecore definition of the model, and this validator is enough to fulfill the non-user requirement.

In order to use the validation provided by EMF, the gmfgen model has to be modified in the way shown in the Figure~\ref{fig:validation_option}
\begin{figure}[htb]
    \centering
    \includegraphics[width=0.95\linewidth]{gfx/validation_option}
    \caption{GMF Graph definition}\label{fig:validation_option}
\end{figure}

The code in Listing~\ref{lst:validation} shows how to force the validation of the request, before its submission to the OGSA-DAI service. If the model is not valid, is possible to iterate through the error showing in a dialog window the error messages.

\lstset{language=Java, caption=WorkflowType and ActivityType schema definition, label=lst:validation}
\begin{lstlisting}
final IStatus status = ValidateAction.runValidation(mySelectedElement.getDiagramView());
if (status.isOK()) {
	MessageDialog.openInformation(shell, "Validation",
		"validation successful");
			
	}  else {
	// Code that shows a dialog listing the errors returned by the function:
	public Object[] getElements(Object inputElement) {
		if (status != null && status.isMultiStatus()
			&& status == inputElement) {
			return status.getChildren();
		} else if (status != null && status == inputElement) {
			return new Object[] { status };
		}
		return new Object[0];
	}
}
\end{lstlisting}


%*****************************************
%*****************************************
%*****************************************
%*****************************************
%*****************************************
%*****************************************
